「SOLID 原則告訴我們該如何將函式和資料結構安排到類別中，及這些類別該如何相互關聯」

「一旦我們應用了 SOLID 原則，我們將與元件(Component)世界同行，接著再進入到高層架構(Architecture)的原則」

取自: Clean Architecture (pp.49-50)

Part III: 設計原則

SOLID 原則起源於本書作者 Uncle Bob 於 1980 年代後期在 USENET 上與各方大神們討論軟體設計原則，幾經增減後歸納出的五大原則，簡述如下：

1. SRP: 單一職責原則
   • 衍生自 Conway 定律
     • 軟體產品的架構與專案團隊的組織結構是相互影響的
   • 因此，每個軟體模組都只有唯一的理由需要改變
     • P.S. 絕對不要跟「每個函式只做一件事」搞混，這不是 SRP!
   • 白話文:
     • 每個模組的改變都只該影響到一個利益相關者(角色, Actor)，模組的改變不該牽動到許多角色
2. OCP: 開放封閉原則
   • Bertrand Meyer 於 1980 年代提出
   • 要使軟體系統易於修改，必須設計成:
     • 「藉由增加新代碼來達成新的行為，而非更動既有代碼」
3. LSP: Liskov 替換原則
   • 1988 年 Barbara Liskov 首度提出、並於 1994 年發表成論文
     • Ref: A behavioral notion of subtyping (1994)
     • 題外話: Liskov 為美國第一位女性資工博士，於 2008 獲得圖靈獎
   • 建置軟體系統必須來自於可互換的部分，這些部分必須遵守允許這些部分相互替換的契約
   • 白話文:
     • 使用繼承時，必須讓父類別和子類別間能夠互相替換，而不影響系統運作
4. ISP: 介面隔離原則
   • 軟體設計者必須避免依賴於不使用的東西
   • 白話文:
     • 不要定義一個包含超多函式的介面給很多不同類別實作，讓每個類別各自對應到最少函式的介面
5. DIP: 依賴反向原則
   • 實作策略的高層級程式碼不應該依賴於實作細節的低層級程式碼。相反地，細節應該依賴於策略

CH7: 單一職責原則 (Single Responsibility Principle, SRP)

「程式設計師很容易因為這個名字，就假設它意味著每個模組都應該只做一件事」

「SRP 的最終版本是: 一個模組應該只對唯一的一個角色負責」

取自: Clean Architecture (p. 53)

案例一

案例二

小結

• 內聚(Cohesive)一詞意味著 SRP。內聚力是種力量，將程式碼綁定在一起，以對角色 (actor) 負責
• 單一職責原則又以不同的形式出現在兩個層次上
  • 在元件 (Component) 層次:
    • 共同封閉原則 (Common Closure Principle, CCP)

    The classes in a component should be closed together against the same kind of changes. A change that affects a component affects all the classes in that component and no other components

    取自: The Common Closure Principle

  • 在架構 (Architecture) 層次:
    • 成為負責建立架構邊界(Boundaries)的變化軸